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ABSTRACT 


This  thesis  develops  and  provides  an  accurate  simulation  model  of  the 
communications  pathway  between  Fleet  Numerical  Meteorology  Oceanographic  Center 
(FNMOC)  Monterey,  California  and  Naval  Atlantic  Meteorology  Oceanographic  Center 
(NLMOC)  Norfolk,  Virginia.  In  order  to  fulfill  its  mission  to  provide  global  weather 
forecasts  to  the  warfighter,  FNMOC  must  provide  timely  data  to  its  customers.  This 
model  provides  an  analytic  approach  toward  determining  time  delay  with  respect  to 
bandwidth  and  its  management.  Additionally,  this  model  enables  the  user  to  analytically 
determine  the  effects  of  hardware  changes.  Although  other  customers  exist  besides 
NLMOC  Norfolk,  it  is  a  major  consumer  of  data  files  in  support  of  weather  forecasting. 
The  other  major  links  are  located  in  Rota,  Spain;  San  Diego,  California;  Yokosuka, 
Japan;  and  Peal  Harbor,  Hawaii.  This  model  is,  however,  scalable  to  simulate  these  other 
major  links.  The  target  audience  for  this  information  model  is  the  technical  support 
personnel  at  FNMOC  Monterey,  California,  who  manage  the  link  to  NLMOC  Norfolk, 
Virginia.  The  information  that  supports  this  model  was  derived  from  field  visits  to 
technical  personnel  at  FNMOC  Monterey.  No  other  communications  software  model  has 
been  developed  at  the  present  time.  The  discrete  event  software  simulation  tool  used  for 
this  model  is  Extend™. 
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THESIS  DISCLAIMER 


The  reader  is  cautioned  that  the  computer  programs  developed  in  this  research 
may  not  have  been  exercised  for  all  cases  of  interest.  While  every  effort  has  been  made, 
within  the  time  available,  to  ensure  that  the  programs  are  free  of  computational  and  logic 
errors,  they  cannot  be  considered  validated.  Any  application  of  these  programs  without 
additional  verification  is  at  the  risk  of  the  user. 
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EXECUTIVE  SUMMARY 


Fleet  Numerical  Meteorology  Oceanographic  Center  (FNMOC)  Monterey,  has  as 
its  primary  mission  to  provide  timely,  global  weather  information  to  the  warfighter.  The 
major  customers  of  this  weather  information  are  located  in  Rota,  Spain;  San  Diego, 
California;  Yokosuka,  Japan;  Pearl  Harbor,  Hawaii;  and  Norfolk,  Virginia.  Each 
customer  is  assigned  its  own  region  of  the  world  to  forecast  and  also  obtains  its  own 
particular  data  via  different  paths  and  at  different  rates  of  data  transfer. 

This  thesis  develops  and  provides  an  accurate  simulation  model  of  the 
communications  pathway  between  Fleet  Numerical  Meteorology  Oceanographic  Center 
(FNMOC)  Monterey,  California  and  Naval  Atlantic  Meteorology  Oceanographic  Center 
(NLMOC)  Norfolk,  Virginia.  NLMOC  Norfolk  was  chosen  because  it  is  a  major 
consumer  of  weather  data.  This  model,  however,  is  scalable  to  simulate  these  other 
major  links  for  future  study. 

To  deliver  weather  data  to  NLMOC  Norfolk,  FNMOC  Monterey  has  developed 
an  architecture  that  ensures  a  timely  response  to  data  requests.  There  are  typically  two 
types  of  data  transfers  that  take  place  every  day  to  NLMOC  Norfolk.  The  first  type  of 
data  transfer  is  a  relatively  small  update  data  file.  Although  requested  with  a  250 
kilobyte  file  it  is  typically  answered  with  a  smaller  size  data  file  of  approximately  100 
kilobytes.  This  request  and  subsequent  response  occurs  approximately  every  fifteen 
minutes.  The  second  type  of  data  transfer  is  extremely  large  and  takes  place  every  twelve 
hours,  also  upon  request.  This  data  file  is  produced  once  all  weather  observations  are 
received  by  FNMOC  Monterey  and  subsequently  input  into  the  weather  forecasting 
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model.  This  weather  forecasting  program  produces  a  very  large,  one  gigabyte  file.  This 
file  is  then  sent  the  NLMOC  Norfolk. 

All  of  these  messages  are  sent  along  the  same  pathway  using  Ethernet  technology. 
As  a  result  of  Ethernet  protocol,  every  twelve  hours  no  other  messages  may  transfer  until 
the  very  large  database  has  been  fully  sent.  These  data  are  sent  and  received  at  the 
maximum  rate  of  a  T-l  line  or  1.544  megabits  per  second  (Mbps).  Although  this  transfer 
rate  is  relatively  fast,  such  immense  data  transfers  cause  a  theoretical  minimum  system 
delay  of  approximately  one  hour  and  twenty-eight  minutes.  This  system  delay  occurs 

every  twelve  hours.  This  data  transfer  rate  and  its  associated  delay  are  the  focus  of  this 
thesis. 

The  pathway  used  to  transfer  data  is  a  commercially  obtained  leased  line.  It  is 
therefore,  always  available  to  both  FNMOC  and  NLMOC  without  interruption  or 
requests  from  other  customers.  Although  the  path  between  Monterey  and  Norfolk  is 
exclusive,  there  still  exist  other  limitations.  The  maximum  data  rate  for  this  line  is 
limited  by  the  rate  at  which  NLMOC  Norfolk  can  receive  data.  NLMOC’s  server  allows 
data  transfer  rates  as  high  as  a  T-l  line  (1.544  Mbps),  however  this  same  server  provides 
email  and  outbound  data  transfer  services  as  well.  This  causes  the  true  inbound  rate  from 

FNMOC  Monterey  to  be  limited  to  approximately  0.56  Mbps  or  36  percent  of  maximum 
T-l  line  speed. 

The  model  is  used  to  develop  and  analyze  three  scenarios.  The  first  demonstrates 
the  transfer  of  typical  data  at  the  maximum  theoretical  T-l  line  rate  of  1.544  Mbps.  Its 
subsequent  time  delay  is  found  to  equal  one  hour  and  twenty-eight  minutes. 
Unfortunately  NLMOC  Norfolk  routinely  experiences  data  delays  of  four  hours  every 
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time  the  one  gigabyte  transfer  occurs.  Their  using  this  same  server  for  other  purposes 
such  as  outbound  customer  traffic  causes  this  further  delay  over  the  maximum  theoretic 
time  delay.  This  delay  could  however,  be  greatly  decreased  if  NLMOC  Norfolk 
purchased  an  additional  server  solely  dedicated  to  receiving  data  from  FNMOC 
Monterey. 

The  second  scenario  determines  typical  time  delays  if  the  entire  line  bandwidth 
were  increased  to  10  megabits  per  second,  which  is  the  current  rate  at  which  FNMOC 
Monterey  is  able  to  transmit  data.  To  achieve  this,  more  bandwidth  would  have  to  be 
purchased  by  NLMOC  Norfolk  through  expanding  the  current  lease  agreement.  At  10 
megabits  per  second  however,  the  time  delay  caused  by  a  one  gigabyte  message  would  be 
decreased  to  13.3  minutes. 

The  third  scenario  demonstrates  expected  time  delays  if  the  one  gigabyte  data  file 
were  managed  differently  and  therefore  allowed  to  be  transferred  in  parts  once  every 
hour,  equally  spread  over  the  standard  twelve  hour  time  period.  Using  the  T-l  line 
already  in  place,  the  time  delay  would  be  decreased  to  7.2  minutes  every  hour  of 
transmission.  This  change  could  be  realized  through  a  management  alteration  to  the 
outbound  data. 

Each  scenario  invokes  a  monte-carlo  algorithm  to  allow  for  actual,  unforeseen 
message  delays.  Each  message  transfer  time  is  sampled  from  a  standard  normal 
distribution  using  its  particular  mean  time  to  send  and  a  standard  deviation  of  five 
seconds. 

The  discrete  event  software  simulation  tool  chosen  for  this  model  is  Extend™, 
developed  by  Imagine  That,  Incorporated  in  San  Jose,  California.  Originally  fielded  in 
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the  early  1990’s,  Extend™  provides  the  user  with  tools  to  develop  a  rigorous  simulation 
on  a  desktop  computer.  It  is  fully  programmable  by  the  user  without  third  party 
contributions.  It  does  this  by  enabling  the  user  to  choose  item  generators,  time  delays, 

and  queues  in  such  a  way  that  a  tailored,  numeric  simulation  can  be  accurately  defined 
and  run. 

This  software  model  provides  an  analytic  approach  toward  determining  expected, 
theoretic  time  delays  with  respect  to  bandwidth  and  its  management.  Additionally,  this 

model  enables  the  user  to  analytically  determine  the  effects  of  proposed,  future  hardware 
changes. 

The  target  audience  for  this  simulation  model  is  the  technical  support  personnel  at 
FNMOC  Monterey,  California,  who  manage  the  link  with  NLMOC  Norfolk,  Virginia. 
The  information  that  supports  this  model  was  derived  from  field  visits  to  technical 
personnel  at  FNMOC,  Monterey,  California. 

At  the  time  of  this  study,  no  other  communications  software  model  had  been 
developed  or  considered  by  FNMOC  Monterey. 
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I.  INTRODUCTION 


A.  BACKGROUND  AND  PURPOSE 

In  today’s  environment  of  constantly  improving  rates  of  data  transfer  and 
potentially  lower  costs  through  system  improvements,  the  potential  to  upgrade  a  system 
is  very  high.  Therefore,  an  analytic  method  to  predetermine  outcomes  and  demonstrate 
effects  of  potential  hardware  and  software  alterations  must  be  developed  and  used 
regularly. 

One  such  method  is  a  simulation  model.  This  model  must  be  capable  of  being 
scalable  and  alterable  to  conform  well  to  current  system  parameters.  It  should  also  be 
capable  of  allowing  the  input  of  actual  data  as  well  as  allow  for  random  number 
generation  in  order  to  produce  the  most  realistic  outcomes.  All  of  this  is  done  so  that 
important  decisions  concerning  system  improvements  can  be  made  wisely  by  those  who 
employ  it  before  embarking  on  the  new  change. 

1.  FNMOC  Monterey 

Fleet  Numerical  Meteorology  and  Oceanography  Center  (FNMOC)  is  located  at 
the  Naval  Postgraduate  School  Annex  on  Airport  Road,  Monterey,  California.  It  is 
supported  by  267  individuals,  of  whom  95  are  military  and  172  are  civilian.  FNMOC 
provides  around-the-clock  operational  oceanographic  and  meteorological  support  to  the 
Department  of  Defense,  U.S.  Navy,  other  U.S.  Government  agencies,  and  elements  of  the 
armed  forces  of  allied  nations.  It  is  a  third-echelon  command  under  the  Chief  of  Naval 
Operations  (CNO),  Oceanographer  of  the  Navy,  located  at  the  Naval  Observatory  in 
Washington,  DC,  and  the  Commander,  Naval  Meteorology  and  Oceanography  Command 
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(CNMOC),  located  at  Stennis  Space  Center  (SSC),  Mississippi.  FNMOC  works  with  its 
four  other  third-echelon  commands  that  include  the  other  production  data  center  at  SSC, 
Naval  Oceanographic  Office  (NAVO),  Naval  Ice  Center  (NAVICE),  Suitland,  Maryland, 
and  three  theater  Meteorology  and  Oceanography  (METOC)  centers:  Naval  Pacific 
METOC  Center  (NPMOC  West)  at  Pearl  Harbor,  Hawaii;  Naval  Atlantic  METOC  Center 
(NLMOC)  at  Norfolk,  Virginia;  and  Naval  European  METOC  Center  (NEMOC)  at  Rota, 
Spain.  Figure  1  illustrates  the  chain  of  command.  FNMOC  also  has  two  detachments 
(FNMOD  s)  that  provide  climatology  support  and  weather  communications  coordination. 
These  detachments,  which  are  located  in  Asheville,  North  Carolina,  and  Tinker  Air  Force 
Base  (AFB),  Oklahoma,  support  the  Navy  and  the  Marine  Corps,  respectively. 


Figure  1 .  FNMOC  Monterey  Chain  of  Command  (From  Ref.  7) 
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NLMOC’s  primary  customers  are: 


•  Northern  European  Meteorology  and  Oceanography  Center  (NEMOC)  in 
Rota,  Spain 

•  Naval  Atlantic  Meteorology  and  Oceanography  Center  (NLMOC)  in  Norfolk, 
Virginia 

•  Naval  Pacific  Meteorology  and  Oceanography  Center  (NPMOC)  in  San 
Diego,  California 

•  Naval  Pacific  Meteorology  and  Oceanography  Center  (NPMOC  WEST)  in 
Pearl  Harbor,  Hawaii 

•  Naval  Pacific  Meteorology  and  Oceanography  Center  (NPMOC  EAST)  in 
Yokosuka,  Japan 

This  study  will  focus  on  the  communication  link  between  FNMOC  Monterey  and 
NLMOC  Norfolk  because  of  the  large  amount  of  data  that  is  routinely  requested  by  them. 

2.  Extend™  Software 

The  discrete  event  software  simulation  tool  chosen  for  this  model  is  Extend™, 
developed  by  Imagine  That,  Incorporated  in  San  Jose,  California.  Originally  available  for 
customer  use  in  the  early  1990’s,  Extend™  provides  the  user  with  tools  to  develop  a 
rigorous  simulation  on  a  desktop  computer.  It  is  fully  programmable  by  the  user  without 
third  party  contributions.  It  does  this  by  enabling  the  user  to  choose  item  generators,  time 
delays,  and  queues  in  such  a  way  that  a  tailored,  numeric  simulation  model  can  be 
accurately  defined  and  run. 
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Extend  uses  a  drag-and-click"  methodology  through  the  use  of  a  many 
different  pre-defined  "blocks."  This  type  of  Graphical  User  Interface  (GUI)  makes  the 
building  of  models  fast  and  accurate.  Most  of  the  "blocks"  available  for  use  within 
Extend  are  used  in  the  model  developed  for  this  study;  the  others  were  user  defined. 
They  will  each  be  explained  in  the  model  chapter  of  this  thesis.  These  blocks  can  be 
opened  to  allow  a  user  to  code  and  thereby  implement  specific  behaviors  within  that 
particular  block.  Many  blocks  can  also  be  aggregated  into  one  block  by  selecting  the 
blocks  desired  and  choosing  the  "make  hierarchical"  option.  This  helps  to  simplify  a 
section  of  the  model,  especially  when  many  blocks  and  their  connections  are  present. 
The  model  developed  in  this  study  uses  this  option  frequently. 

Blocks  awaiting  use  are  saved  and  maintained  in  separate  "libraries."  The  user 
opens  these  libraries  as  necessary  so  that  the  block  can  be  retrieved.  Once  the  blocks  are 
connected  and  attributes  are  assigned  to  each  block  the  model  is  ready  to  run.  More 
details  concerning  blocks  and  hierarchical  design  will  be  discussed  in  the  model 
description  chapter. 

Extend™  also  provides  user  output  in  many  forms.  For  example,  a  plotter  block 
can  be  chosen  that  will  automatically  graph  the  desired  output.  This  same  output  will  be 
used  to  show  the  results  of  the  model  developed  for  this  thesis.  It  also  provides  the 
numbers  that  make  up  the  plot  so  that  the  user  can  perform  further  data  analysis  if 
necessary.  Additionally  Extend™  allows  the  user  to  select  an  animation  option,  which 
reveals  item  location  during  the  simulation.  Although  it  causes  the  simulation  to  run 
much  slower  it  is  most  helpful  in  model  debugging  and  demonstration. 
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B.  OBJECTIVE 


The  objective  of  this  thesis  is  to  provide  a  simulation  model  of  the  connection 
between  NLMOC  Norfolk  and  FNMOC  Monterey.  This  model  will  allow  modifications 
in  order  to  evaluate  the  effects  of  proposed  system  changes.  In  particular  this  model  will 
be  able  to  run  on  a  Pentium  III™,  500  megahertz,  desktop  computer  and  produce  usable 
output. 

C.  RESEARCH  TOPICS 

Research  topics  explored  by  this  thesis  are  divided  among  three  excursions.  The 
first  excursion  will  determine  the  current,  minimum  theoretic  time  delay  of  transferring  a 
one  gigabyte  message  to  from  FNMOC  Monterey  to  NLMOC  Norfolk  using  a  standard 
T-l  line  rate  of  1.544  Mbps. 

The  second  excursion  demonstrates  the  minimum  theoretic  time  delay  of 
transferring  a  one  gigabyte  message  to  from  FNMOC  Monterey  to  NLMOC  Norfolk 
using  an  improved  bit  transfer  rate  of  10  Mbps.  This  excursion  is  extremely  useful 
because  NLMOC  Monterey  is  current  able  to  send  data  at  that  rate,  but  NLMOC  Norfolk 
can  only  receive  at  1.544  megabits  per  second.  However,  it  can  upgrade  its  line  speed 
through  expanding  its  leased  line  service  agreement. 

The  third  excursion  demonstrates  the  effects  of  parsing  the  one  gigabyte  message 
into  twelve  equal  parts  and  allowing  them  to  be  sent  once  every  hour.  The  line  speed 
used  in  this  case  is  1.544  megabits  per  second,  which  is  already  in  place. 
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II.  FNMOC  OPERATIONS 


A.  DATA  GATHERING 

FNMOC  Monterey  receives  thousands  of  observations  every  day.  These 
observations  are  input  into  a  very  robust  program  entitled  the  Naval  Operational  Global 
Atmospheric  Prediction  System  (NOGAPS).  It  has  the  ability  to  compare  current 
readings  with  previously  held  data  and  run  an  algorithm  to  determine  the  weather  forecast 
for  a  particular  region. 

B.  DATA  TRANSMISSION 

Once  the  data  have  been  produced  by  POPS  they  are  placed  into  geographically 
"gridded"  binary  files,  referred  to  as  "grib"  files.  These  "grib"  files  are  then  sent  and 
stored  in  an  internal  database,  where  they  await  further  transfer  once  a  customer’s  request 
is  received. 

Requests  for  data  arrive  from  NLMOC  Norfolk  approximately  every  fifteen 
minutes.  They  are  typically  250  kilobytes  in  size.  These  requests  are  answered  using 
recently  updated  files  which  are  relatively  smaller,  approximately  100  kilobytes  in  size. 

However,  once  every  twelve  hours,  NLMOC  Norfolk  requests  that  the  entire 
database  be  updated.  Using  a  250  kilobyte  message,  this  request  is  made.  It  is  then 
answered  by  sending  a  large,  one  gigabyte  message  containing  the  entire  database. 

C.  HARDWARE 

FNMOC  Monterey  operates  three  Cray™  Supercomputers  and  two  OASIS  Sun™ 

Minicomputers  in  order  to  run  and  store  its  forecast  programs  and  data.  Combined  with 

resident  switches  and  routers,  this  information  is  received  and  transferred  internally 
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within  FNMOC  Monterey  at  a  "Fast  Ethernet"  speed  of  10  Mbps.  However,  these  data 
are  sent  externally  from  FNMOC  Monterey  at  the  maximum  rate  of  a  T-l  line  or  1.544 
Mbps.  The  limiting  factor  is  NLMOC  Norfolk’s  ability  to  receive  data  from  FNMOC 
Monterey.  NLMOC  Norfolk  is  limited  to  T-l  line  speed  for  both  receiving  and  sending 

data.  Therefore  this  model  simulates  the  bandwidth  of  1.544  as  a  starting  point  in  the 
analysis. 
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III.  MODEL  DESCRIPTION 


A.  OVERVIEW 

The  model  developed  for  this  study  simulates  an  Ethernet  operating  at  different 
bandwidths  and  thereby  allows  message  traffic  to  be  transferred  at  different  rates.  This 
model  also  determines  expected,  theoretic  time  delays  of  message  traffic  and  Ethernet 
utilization  with  respect  to  bandwidth  and  its  management.  This  analytical  approach  is 
especially  useful  when  determining  the  effects  of  proposed  system  changes.  The 
software  Extend™  chosen  for  this  model  simulates  well  the  individual  parts  of  the 
sending  and  receiving  nodes  and  the  required  Ethernet  of  the  overall  communication 
system.  Extend™  refers  to  these  individual  parts  as  "blocks". 

1.  Building  "Blocks” 

Extend™  uses  predefined  scripts  of  computer  code  known  as  "blocks"  and 
represents  each  of  them  with  a  highly  descriptive  icon.  Each  block  has  its  own 
characteristics  and  is  easily  selected  by  the  user  when  its  library  is  opened.  Blocks  of  a 
similar  type  are  aggregated  together  into  one  library.  Once  opened,  each  library  remains 
available  for  that  particular  model.  This  allows  the  model  itself  to  be  smaller  in  terms  of 
required  memory  because  the  model  itself  simply  references  each  block’s  computer  code 
resident  in  each  library  during  the  simulation  run. 

Additionally  double  clicking  on  it  will  access  each  block.  It  will  either  display  its 
"dialogue  box"  or  if  "hierarchical",  it  will  display  the  blocks  that  it  contains.  If  a  dialog 
box  is  displayed,  the  user  is  prompted  for  additional  information  particular  to  that  block 
selected.  The  dialog  box  also  contains  a  complete  explanation  of  all  connections  to  that 
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particular  block  and  what  the  block  itself  is  capable  of  accomplishing.  This  information 

can  range  from  maximum  queue  length  to  message  data  sizes  depending  on  the  block 
chosen. 

2.  Hierarchy 

Although,  the  model  appears  at  first  to  be  fairly  simple,  Extend™  allows  for 
blocks  to  be  "buried"  beneath  other  blocks.  Extend™  allows  the  user  to  select  blocks  and 
provides  the  option  for  them  to  be  made  "hierarchical".  This  in  tum  gathers  all  of  the 
chosen  blocks  and  places  one  hierarchical  block  in  their  place.  All  of  the  connections 
previously  used  are  still  intact  with  system  chosen  names  as  illustrated  in  the  model 
description  chapter.  Although  all  of  the  blocks  are  accessed  and  used  in  sequence,  this 
optional  use  of  hierarchy  is  especially  useful  when  there  are  too  many  connections  or  too 
many  blocks  for  the  user  to  view  everything  clearly.  This  option  can  also  be  chosen 
many  times  once  sub-blocks  are  defined.  Therefore  many  layers  can  be  contained  within 
each  model.  The  model  developed  for  this  thesis  has  four  layers. 

B.  BLOCK  DESCRIPTION 
1.  FNMOC  Monterey 

The  hierarchical  block  containing  the  FNMOC  logo  represents  this  portion  of  the 
model.  As  Figure  2  illustrates,  it  has  four  connections  available  for  traffic  flow  into  the 
Ethernet  block  for  eventual  traffic  to  the  NLMOC  Norfolk  block. 
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Although  it  is  possible  for  messages  to  flow  from  Monterey  back  into  Monterey 
using  this  model,  there  is  no  traffic  directed  in  this  fashion.  In  the  upper  left-hand  comer 
of  Figure  2,  there  is  also  a  clock  icon  indicating  to  Extend™  that  this  will  be  a  discrete 
event  model. 
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NOGAPS 


a. 

By  double  clicking  on  the  FNMOC  Monterey  block,  the  layer  beneath  the 
block  is  revealed.  Figure  3  illustrates  this  next  layer. 
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Figure  3.  FNMOC  Monterey  Block  (Inputs  and  Outputs) 


The  block  represented  by  the  Tropical  Atlantic  Naval  Operational  Global 
Atmospheric  Prediction  System  (NOGAPS)  logo  indicates  the  portion  of  the  model 
where  the  large  data  transfer  is  originated.  This  data  is  sent  every  twelve  hours  to 
NLMOC  Norfolk. 

b.  Web  Server 

The  web  server  block  immediately  adjacent  to  the  NOGAPS  block,  both 
receives  requests  for  data  and  sends  updated  data  from  FNMOC  Monterey  every  fifteen 
minutes  via  the  Ethernet  connection.  All  messages  are  destined  for  NLMOC  Norfolk  via 
the  Ethernet  block.  The  typical  message  sizes  are  250  kilobytes  received  and  100 
kilobytes  sent.  This  message  traffic  mimics  the  actual  data  sizes  for  messages  that 
request  forecast  weather  updates  and  the  update  itself  respectively.  This  data  is  also 
allowed  to  vary  in  time  by  using  a  standard  normal  distribution  with  a  mean  of  sending  a 
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message  every  15  minutes  and  a  standard  deviation  of  five  seconds.  This  more 
realistically  simulates  unforeseen  line  delays. 
c.  For  Future  Use 

Both  blocks  in  Figure  3  that  read  "For  Future  Use"  are  intended  for 
potential  studies  to  be  accomplished  beyond  the  scope  of  this  thesis.  However,  each  will 
generate  and  receive  message  traffic  as  directed  by  the  user  just  as  the  other  blocks. 


Packets  ]p - 10”"20"'  ] 

Msg  Blocking 

Figure  4.  FNMOC  Monterey  Block  (Message  Generation) 

(1)  Message  Generation  with  Attributes.  The  first  block  in 
Figure  4  actually  generates  messages  for  the  simulation.  It  is  here  that  the  user  defines 
the  timing  of  each  message.  In  this  case  the  large  data  message  is  sent  once  every  twelve 
hours.  However,  it  is  also  allowed  to  be  sent  early  or  late  within  a  five  second  standard 
normal  distribution  with  a  mean  of  twelve  hours. 

The  next  block  receives  the  item  and  appends  user-defined 
attributes  onto  it.  This  block  is  also  hierarchical  and  is  illustrated  in  Figure  5. 
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Figure  5.  FNMOC  Monterey  Block  (Message  Attributes) 

It  is  finally  within  this  layer  that  the  message  receives  all  of  its 
attributes  such  as  destination,  message  size,  and  message  identification.  The  first  block 
in  Figure  5  is  the  system  assigned  connection  for  the  generated  message  that  is  input  from 
the  previous  layer.  The  next  block  provides  the  message  with  a  randomly  chosen 
message  identification.  Once  set,  the  message  identification  is  requested  using  the  block 
marked  Get  A  for  get  attribute".  This  identification  is  used  to  select  a  row  of  data  in 
the  file  block.  That  row  of  data  contains  the  message’s  destination  and  size  in  bytes. 
Each  message  now  contains  its  own  discrete  data  and  is  stamped  with  a  system  time.  The 
system  time  will  support  the  measurement  of  time  delay  for  the  Ethernet. 

Referring  once  again  to  Figure  4,  the  message  with  all  of  its 
attributes  is  sent  into  a  first-in-first-out  (FIFO)  queue  as  required  by  Extend™  for  the 

purpose  of  model  integrity.  This  is  done  to  ensure  that  no  messages  are  lost  in  transition. 
The  messages  are  then  sent  to  the  packet  building  block. 
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(2)  Packet  Building  Block.  In  this  block  each  message  is 


simply  parsed  into  the  correct  number  of  packets  for  the  Ethernet. 


Packet"  size 
(Bytes) 


Figure  6.  FNMOC  Monterey  Block  (Build  Packets:  First  Half) 

As  illustrated  in  Figure  6,  the  block  again  first  starts  with  the 
hierarchical  connection  set  by  the  system.  The  message  then  goes  into  a  service  activity 
block,  which  serves  as  a  conditional  wait.  This  ensures  that  it  is  the  only  message  being 
serviced  at  the  present  time.  The  logical  block  beneath  it  provides  the  logical  input  of 
"full"  if  the  final  FIFO  queue  of  this  block  is  not  empty. 

Next  the  message  is  asked  for  its  size.  That  size  is  divided  by  1500 
which  is  the  standard  Ethernet  packet  size.  This  renders  the  number  of  packets  required 
by  this  message.  The  message  is  now  sent  into  another  FIFO  queue  after  which  the 
number  of  packets  is  requested  from  it.  Figure  7  illustrates  what  happens  next. 
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Figure  7 .  FNMOC  Monterey  Block  (Build  Packets:  Second  Half) 

In  Figure  7  the  message  is  then  selected  according  to  its  size.  Only 
a  message  smaller  than  1500  bytes  is  allowed  to  travel  along  the  "A"  pathway  where  it 
will  be  stamped  Last  Packet",  all  other  inbound  messages  are  sent  along  the  "B" 
pathway.  Last  packet  will  later  be  used  as  output  to  count  the  number  of  messages 
processed  through  the  system.  Next  they  arrive  at  second  block  above  marked  with  an  "a, 
b  or  c"  output.  This  "unbatch"  block  takes  the  inbound  message  and  duplicates  it, 
sending  one  cops  to  be  stamped  "last  packet"  and  one  copy  to  take  on  the  value  of  the 
number  of  packets  it  requires.  These  items  are  all  rejoined  and  sent  to  the  final  FIFO 
queue  u  here  the  number  of  packets  are  sent  followed  by  the  last  packet.  Once  the  queue 

is  empt\  the  logical  variable  "full"  is  reset  to  zero  allowing  the  next  message  to  be 
processed. 

From  here  the  packets  are  all  sent  via  the  outbound  connection  to 
the  Ethernet  block  for  further  processing. 
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2.  Ethernet 


This  portion  of  the  model  is  represented  by  a  user  defined  Ethernet  block.  As 
Figure  8  shows,  eight  connections  are  available,  this  model  uses  five  of  them.  Four  of  the 
connections  are  from  NLMOC  Monterey  and  one  leads  to  NLMOC  Norfolk. 


Figure  8.  Ethernet  Block  (First  Half) 


As  Figure  8  illustrates,  all  of  the  nodes  have  an  inbound  connection.  As  packets 
arrive  they  are  immediately  sent  into  a  hierarchical  block  where  bandwidth  is  verified  and 
therefore  time  delay  is  determined.  Afterwards,  each  packet  is  asked  if  it  is  the  "last 
packet".  If  it  is  the  "last  packet"  then  it  is  sent  along  the  path  marked  "b"  and  one 
message  is  counted.  All  packets,  including  the  "last  packet"  are  then  gathered  and  sent  to 
the  second  half  of  this  block  as  if  Figure  9. 
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Figure  9.  Ethernet  Block  (Second  Half) 


As  Figure  9  illustrates  the  inbound  packets  are  all  gathered  and  copies  are  sent 
into  another  FIFO  queue  where  their  destination  is  queried  and  into  an  output  to  count  all 
processed  packets.  Packets  are  then  sent  onward  to  their  proper  and  final  destination. 
a.  Ethernet  Bit  Rate  Delay 

Figure  8  shows  this  hierarchical  block,  which  is  further  illustrated  in 
Figure  10  below. 


Figure  10.  Ethernet  Block  (Bit  Rate  Delay) 
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As  Figure  10  begins,  packets  are  brought  in  via  the  system  connection  and 
put  into  a  "last-in-first-out"  (LIFO)  queue.  This  allows  for  simple  packet  collision 
modeling  by  allowing  the  last  packet  to  simply  go  first.  Therefore,  in  the  event  that  two 
or  more  packets  should  be  competing  for  Ethernet  processing,  the  last  one  entering  will 
be  serviced  first.  This  "back-off  of  packet  processing  simulates  in  a  simple  manner  the 
transfer  protocol  used  for  Ethernet  processing. 

This  model  realistically  will  have  no  collisions  because  of  the  small 
amount  of  message  traffic  and  because  the  line  used  between  FNMOC  Monterey  and 
NLMOC  Norfolk  is  a  dedicated  line  without  any  requests  or  messages  originating  from 
other  customers.  However,  if  more  customers  were  added  in  the  future,  a  more  robust 
collision  algorithm  would  have  to  be  written  for  this  model. 

Next  each  packet  is  asked  for  its  size  which  is  generally  1500  bytes  unless 
it  is  the  last  packet  when  it  may  be  less.  The  correct  time  delay  is  determined  by  dividing 
the  size  of  the  packet  by  the  bandwidth  available.  The  percent  of  utilization  of  the 
Ethernet  is  then  output  and  the  packet  is  sent  to  complete  the  Ethernet  block. 

3.  NLMOC  Norfolk 

This  block  is  represented  by  the  NLMOC  Norfolk  logo.  It  has  one,  two-way 
connection  available  from  the  Ethernet  block  available  for  traffic  flow.  It  also  contains 
the  same  hierarchical  blocks  for  sending  and  receiving  messages.  However  the  data  it 
sends  corresponds  to  250  kilobyte  size  request  messages.  These  messages  like  their 
corresponding  replies  from  FNMOC  Monterey,  are  allowed  to  vary  according  to  a 
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standard  normal  distribution  with  a  mean  of  fifteen  minutes  and  a  standard  deviation  of 
five  seconds. 


a.  Packet  Reception 


As  illustrated  in  Figure  11,  packets  arrive  at  their  destination  having 

© 


completed  the  generation  and  Ethernet  processing. 


LBWB 

Destin  Msg  Que 


Figure  1 1 .  NLMOC  Norfolk  Block  (Packet  Reception) 


Packets  are  then  sent  into  a  FIFO  queue  for  model  integrity  and  sent 
immediately  to  the  unpacking  block.  Figure  12  illustrates  how  packets  are  unpacked. 


Figure  1 2.  NLMOC  Norfolk  Block  (Packets  Unpacked) 
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Packets  are  first  queried  if  it  is  the  last  packet.  If  the  packet  is  the  last 
packet  then  it  is  selected  to  follow  along  the  "b"  path  and  a  complete  message  is  counted. 
Otherwise  the  packet  exits  along  the  "a"  path  and  it  is  counted  as  a  single  packet. 

4.  Output 

The  output  block  gathers  and  displays  the  chosen  data  from  each  model  run.  As 
Figure  13  illustrates,  this  block  reads  the  Ethernet  utilization,  as  well  as  messages  and 
packets  processed  by  the  network. 

Output 

NumPackets 
NumMsgs  - 


Sample  Rate 

Figure  13.  Output  Block 

The  first  block  labeled  with  an  "R"  takes  as  its  input  the  Ethernet  utilization.  This 
is  sampled  every  half  second,  as  directed  by  the  "Sample  Rate"  block.  Additionally  all 
counters  and  activities  are  cleared  once  a  new  input  is  received.  This  ensures  that  no 
aggregation  of  data  occurs.  Three  plotter  blocks  are  then  given  these  outputs  to  plot. 
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IV.  MODEL  RESULTS 


A.  OVERVIEW 

The  model  was  run  on  a  desktop,  Pentium  III™,  500-megahertz  computer.  Each 
complete  run  required  approximately  20  minutes  to  complete.  Each  run  is  executed  for 
5200  seconds.  This  provides  enough  time  for  each  contributing  node  to  complete  its 
transmission  and  eventual  reception  of  data.  Originally  longer  run  times  were  explored; 
however,  the  model’s  behavior  remained  the  same  whether  it  was  run  for  14.4  hours  or  26 
hours.  The  only  difference  was  that  the  graphic  output  became  more  difficult  to  read. 

Additionally,  the  model  was  run  for  three  different  excursions.  Each  excursion 
below,  detailed  on  Table  1,  is  motivated  by  highly  probable  upcoming  proposals  with 
regard  to  system  improvements. 


Excursion 

Bandwidth 

Message  Traffic 

1 

1.544  Mbps  (T-l) 

•  NLMOC  Requests  updates  every  15  min.  (250KB) 

•  FNMOC  Sends  update  every  15  min.  (100KB) 

•  FNMOC  Sends  1  GB  every  12  hours. 

2 

10  Mbps 

•  NLMOC  Requests  updates  every  15  min.  (250KB) 

•  FNMOC  Sends  update  every  15  min.  (100KB) 

•  FNMOC  Sends  1  GB  every  12  hours. 

3 

1.544  Mbps  (T-l) 

•  NLMOC  Requests  updates  every  15  min.  (250KB) 

•  FNMOC  Sends  update  every  15  min.  (100KB) 

•  FNMOC  Sends  83.3  MB  every  hour. 

Table  1.  Excursion  Data 


B.  EXCURSION  ONE  (T-l  LINE) 

For  the  first  excursion  the  available  bandwidth  used  is  1.544  megabits  per  second 
over  the  Ethernet.  This  is  the  standard  T-l  bandwidth.  As  Figure  14  indicates,  the 
Ethernet  runs  smoothly,  with  100  percent  utilization  occurring  only  every  16  minutes 
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approximately  and  lasts  for  less  than  one  second.  This  occurs  until  the  very  large,  one 
gigabyte  data  transfer  commences.  When  this  occurs,  all  other  Ethernet  traffic  is  delayed 
approximately  one  hour  and  twenty-eight  minutes  as  shown  in  the  heavily  shaded  region 
in  Figure  14  below. 


13000  26000  39000  5200C 

Time  (secs) 

—  Ethernet  Utiliz  — 


Figure  14.  1  GB  Message  Sent  Every  12  Hours  via  T-l  Line  (1.544  Mbps) 

C.  EXCURSION  TWO  (10  MEGABITS  PER  SECOND) 

For  the  second  excursion  the  available  bandwidth  used  is  improved  to  10 
megabits  per  second  over  the  Ethernet.  This  was  done  because  FNMOC  Monterey  is 
able  to  transfer  data  at  10  megabits  per  second  even  though  NLMOC  Norfolk  can  only 
receive  data  at  the  standard  T-l  bandwidth.  However  by  expanding  the  service  level 
agreement  NLMOC  Norfolk’s  receive  rate  could  be  improved.  As  expected,  Figure  15 
illustrates  that  the  Ethernet  runs  even  more  smoothly  than  before,  with  typical  maximum 
Ethernet  utilization  remaining  at  20  percent.  This  occurs  approximately  every  16 
minutes.  Additionally,  when  the  very  large,  one  gigabyte  data  transfer  occurs,  the 


24 


Ethernet  is  delayed  approximately  3  minutes  -  a  decrease  of  one  hour  and  twenty-five 


minutes. 


Utilization 


Figure  15.  1  GB  Message  Sent  Every  12  Hours  via  10  Mbps  Line 


D.  EXCURSION  THREE  (T-l  LINE:  HOURLY  OUTPUT) 

The  third  excursion  uses  an  available  bandwidth  of  1.544  megabits  per  second, 
the  same  as  the  first  excursion.  However  in  this  scenario,  the  large,  one  gigabyte  file  is 
parsed  into  twelve  equal  parts  of  83.3  megabytes  instead  of  being  sent  all  at  one  time. 
Each  part  is  then  transmitted  every  hour.  This  could  be  accomplished  through  a  change 
in  the  management  of  the  outbound  database.  As  Figure  16  indicates  the  Ethernet  runs 
fairly  smoothK.  uith  100  percent  utilization  occurring  every  fifteen  minutes  as  well  as 
every  hour  when  the  83.3  megabyte  file  is  sent.  However  the  Ethernet  delay  is  now  just 
7.2  minutes  every  hour  as  a  result  in  the  change  of  data  management. 
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Figure  16.  83.3  MB  Message  Sent  Every  Hour  via  T-l  Line 
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V.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  CONCLUSIONS 

Although  data  is  routinely  sent  via  a  dedicated  leased  line  from  FNMOC 
Monterey  to  NLMOC  Norfolk,  the  time  delay  experienced  by  sending  a  one  gigabyte 
message  once  every  twelve  hours  is  one  hour  and  twenty-eight  minutes.  This  delay 
causes  all  other  traffic  to  wait  until  this  message  completes  its  transmission.  If  the  line 
bandwidth  were  improved,  or  if  the  size  of  the  message  were  decreased  by  allowing  parts 
of  it  to  be  sent  incrementally,  this  line  delay  would  either  be  decreased  or  at  least  occur 
for  much  shorter  periods  of  time  and  less  often. 

1.  NLMOC  Norfolk 

NLMOC  is  a  major  recipient  of  weather  data.  The  files  that  it  receives  are  then 
added  to  other  observations  in  order  to  service  its  customer  as  well.  However,  as  is 
typical  among  users  of  data  of  all  types,  NLMOC  Norfolk  routinely  requests  all  the  data 
that  can  be  sent.  Although  they  could  request  fewer  files  they  currently  request  as  much 
data  as  is  available.  This  is  done  to  achieve  the  most  up  to  date  forecasts  in  support  of 
fleet  operations  and  seems  reasonable  with  respect  to  urgent  operations.  Unfortunately, 
in  terms  of  available  bandwidth,  this  is  not  very  economical.  Although  it  is  beyond  the 
scope  of  this  thesis,  if  there  were  some  method  of  reducing  the  data  requested  this  would 
also  reduce  the  time  delay. 

B.  RECOMMENDATIONS 

The  goal  of  this  thesis  is  to  allow  the  user  the  opportunity  to  simulate  proposed 
system  changes  to  the  connection  between  FNMOC  Monterey  and  NLMOC  Norfolk. 
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Having  completed  three  excursions  with  this  model  the  first  goal  of  simulating  actual  line 
delay  was  accomplished.  Additionally,  the  second  goal  was  to  explore  the  effects  of 
altering  the  system  through  changing  the  bandwidth.  This  alternative  indicates  an 
immense  decrease  in  message  time  can  truly  be  achieved,  especially  if  bandwidth  could 
be  improved  to  10  megabits  per  second. 

Finally,  in  allowing  the  current  system  to  be  altered  to  allow  data  to  be  sent  every 
hour  instead  of  once  every  twelve  hours  also  shows  a  great  decrease  in  system  time  delay. 
In  choosing  between  these  two,  the  second  should  likely  be  chosen  because  it  also  seems 
to  be  the  least  expensive  of  the  excursions  explored. 

Additionally,  as  the  budget  allows,  greater  bandwidth  should  be  purchased  to 
allow  quicker  transmission  of  the  requested  data.  However  this  line  bandwidth  should 

not  exceed  10  megabits  per  second  because  FNMOC  Monterey  is  unable  to  send  it  any 
faster. 
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